Along with maturation of the IP multicast technique, application of the IP multicast is becoming increasingly widespread. However, in an P model, any host can join into any of the multicast groups without limitation, and until now, there are no effective methods that can solve the controlled join problem of a host in an IP multicast network.
It is well known that, in the IP multicast model, a multicast group comprises senders and receivers, which are connected with a multicast Distribution Tree. When the sender needs to send data to a certain group, the host will transmit the data directly to the multicast router which connects with the host, and the multicast router then forwards the data to the multicast receiver via the multicast Distribution Tree without any limitation on the host that sends messages. As soon as a host wants to get data from a certain multicast group, the host sends a Member report message to its connected multicast router according to an Internet Group Management Protocol (IGMP for short), and the multicast router will then forward the data of the multicast group to the host after the Member report message is processed; similarly, the multicast router will not make any limitations on the host which wants to obtain the multicast message. With the development of commercialization in IP multicast application, multicast security has become an urgent problem that should be solved as soon as possible, a key of which is prohibiting unauthorized receivers to receive the multicast messages.
Norihiro Ishikawa et al proposed an IGMP extension protocol “IGMP Extension for Authentication of IP Multicast” (published at draft-ietf-idmr-igmp-auth-01.txt) and a RADIUS extension protocol. “RADIUS Extension for Multicast Router Authentication”, (where, the RADIUS is abbreviation of Remote Authentication Dial In User Service, which is published at draft-yamanouchi-RADIUS-ext-00.txt), with which authentication for the sender and the receiver can be made.
The IGMP extension protocol above is extension made based on an IGMP V2 (version 2), in which authentication function for the multicast sender and the multicast receiver is added, to prevent unauthorized users from sending/receiving multicast packets. The IGMP extension protocol adopts a Challenge-Response mechanism that is similar with a PPP authentication protocol CHAP (Challenge Handshake Authentication Protocol) such as thrice handshakes, encrypted password to make user authentication. Once a multicast sender begins to transmit IP multicast messages, an Ingress router may make authentication for it with the challenge-response mechanism. The Ingress router may utilize a RADIUS as an authentication server during the authentication process. When the authentication is successful, the multicast packets from the sender will be forwarded by the Ingress router to the IP multicast network and then to an Egress router. When the authentication is failed, the Ingress router will discard the multicast packets silently. Authentication made by the Egress router is needed when the multicast receiver wants to receive IP multicast messages. The Egress router may also adopt the RADIUS as the authentication server during the authentication process. Once the authentication succeeds, the Egress router begins to transmit the IP multicast packets to the receiver; Otherwise, no IP packets will be forwarded to the receiver.
The RADIUS extension protocol above is extension made in the basis of the RADIUS, which may make authentication for the multicast sender and the multicast receiver at the Ingress router and the Egress router, and track multicast data of the user to provide data for service management. The authentication server must be able to provide the authentication service required by the multicast router, meanwhile, the multicast router might provide identification (User ID) and password of the user. In order to insure security, authentication process must be based on the challenge, and every service must be authenticated, for instance, authentication must be made on the address of each multicast group. The reason is that multicast packets are transmitted according to the group address, and the authority of the user should be correlative with the group. Except for some additional attributes, other requirements are just the same with that of the RADIUS. Whether or not the multicast router makes RADIUS authentication is optional.
When being configured to support RADIUS charging, the multicast router will generate a charging start message at the beginning of the multicast service, and send to a RADIUS multicast charging server, wherein the message describes type of the service. After receiving the charging start message, the RADIUS multicast charging server will return a confirmation message. When the multicast service is completed, the multicast router also generates a charging end message, and sends the message to the RADIUS multicast charging server. After receiving the message, the RADIUS multicast charging server will also return a confirmation message, wherein the charging end message describes type of the service.
After receiving an IGMP Join request, the multicast router sends an Access-Request message to a RADIUS multicast authentication server to ask for authentication. After receiving a response from the RADIUS multicast authentication server that indicates the authentication is successful, the multicast router sends an Account-Request/Start message to the RADIUS multicast charging server to start charging. While receiving an IGMP Leave request, the multicast router may send an Account-Request/Stop message to the multicast charging server to terminate the charging. If no response is returned to the multicast router within certain period of time, the RADIUS extension protocol advices the multicast router to resend the Access-Request message several times continuously. The multicast charging server can also ask other servers (such as a proxy sever) to implement the charging function. While being unable to record charging message successfully, the multicast charging server cannot send an Accounting-Response confirmation message to the multicast router.
Moreover, a mean of a forwarding table of a layer 2 equipment controlled by a layer 3 equipment, which can control authorized reception in a certain extent, has been provided. As shown in FIG. 1, controlling message used for controlling the forwarding table of a layer 2 equipment is composed by number of edition (Ver, 4 bits), Type (3 bits), Reserved part (2 bytes), number of GDA/USA pairs in the message (Count, 1 byte) and several GDA/USA pairs. Wherein, the GDA (Group Destination Address) is a MAC multicast address that corresponds to an IP address of the multicast group that the host wants to join in; the USA (Unicast Source Address) is a MAC address of the host which wants to join in the multi cast group and is a unicast address.
As shown in FIG. 2, process of the mean of forwarding table of a layer 2 equipment controlled by a layer 3 equipment is as follows. Host 1 sends an IGMP Membership Report message to join in multicast group 224.1.2.3; the switch uses MAC address 0100.5e01.0203 that corresponds to the address of multicast group resoluted from the message to search its matching terms in a CAM (CAM: Content-Addressable Memory) table; because there is no its matching terms in the CAM table, the message is forwarded (flooding) to all the ports, including a CPU and multicast routers. Wherein, after receiving the IGMP Membership Report message, the multicast router, besides implementing routine disposal, produces a join message and multicasts to the switch, which comprises the MAC address (USA: 0080.c7a2.1093) of the host which applies to join in the multicast group, the MAC address (GDA: 0100.5e01.0203) of the multicast group which is applied to join in, as well as a Join command field. After receiving the Join message, the switch may add an entry in the CAM table, which includes the GDA (0100.5e01.0203 in the drawings), the port number (marked as 2 in the drawings) of the host which wants to join in the multicast group, and the port number (marked as 1 in the drawings) of the multicast router that connects with the switch. Wherein, the port number of the host is obtained through searching the USA.
As shown in FIG. 3, when the fourth host 4 joins in multicast group 224.1.2.3, it will similarly send the IGMP Membership Report message to the switch; after having resoluted the IP address of the destination group is 224.1.2.3, the switch may find the entry after searching in the CAM table with the corresponding MAC address 0100.5e01.0203 of the IP address, and forward the message to port 1 and 2 (which are the multicast router and host 1 respectively) listed in the entry. After receiving the IGMP Membership Report message, besides making routine disposal, the multicast router produces a Join message and multicasts to the switch, which comprises the MAC address of the host which applies to join in the multicast group (USA: 0800.c7b3.2174) and the MAC address (GDA: 0100.5e01.0203) of the multicast group which is applied to join in, as well as the Join command field. After receiving the Join message, the switch may obtain an entry through searching in the CAM table with GDA, and get port number 5 of host 4 via searching in the CAM table with USA, meanwhile add port number 5 in the entry.
Although the Synergic extension method between the IGMP and the RADIUS above has solved the authorization problems for the sender and the receiver, some shortcomings still exist.
(1) Once a host join in the multicast group successfully in a shared network, all the other hosts will be able to receive the multicast data, which means, it is impossible to prevent the unauthorized hosts from receiving the multicast data. If a key method is adopted to solve the problem, distribution of keys before authentication for each host will bring numerous limitations and troubles.
(2) If both these two protocols are adopted, it is necessary not only to renew the multicast router equipment, but also to modify IGMP software in the host side. Furthermore, none of these two protocols is standardized; the present hosts don't support the IGMP extension.
Defects of the mean of a forwarding table of a layer 2 equipment controlled by a layer 3 equipment can be notices as follows.
(1) No relation between forwarding control on the layer 2 switch controlled by the multicast router and authorized reception of the host/user is provided, and no authenticating and authorizing method for the user to join in the multicast group is provided either, all the control methods provided are a control method for the multicast message of the layer 2 switch flooding at its port.
(2) The multicast router cannot detect “Silent Leave” of the host/user.